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REMARKS/ARGUMENTS 

This application is under final rejection. Applicants have presented arguments below that 
Applicants believe should render the claims allowable. In the event, however, that the Examiner 
is not persuaded by Applicants' arguments, Applicants respectfully request that the Examiner 
enter the amendment to clarify issues upon appeal. 

The amendment is in response to the Final Office Action dated June 3, 2004. Claims 1- 
25 are pending in the present invention. Applicants have amended claims 1, 10, 15 and 17. 
Accordingly, claims 1-25 remain pending. 

Amended Claims 

Applicants amended independent claims 1, 10, 15 and 17. The amendments cancel 
language referring to a package, where "the package includes a predefined group of objects." No 
new matter has been presented. 

35U.S.C. §112 Rejections 

The Examiner rejected claims 1-25 under 35 U.S.C. §112, 1 st paragraph. The Examiner 
stated that claims 1, 10, 15 and 17, failed to define the metes and bounds of the "predefined 
collection of objects" and that the phrase was new matter. In addition, the Examiner stated that 
the limitation of "accessing the package data" by the resolution module was new matter "because 
the specification of the instant application did not disclose any accessing algorithm or function 
for the claimed resolution module to perform the claimed accessing operation." 

In response to the Examiner's rejection, Applicants have canceled the reference to a 
"predefined collection of objects" from claims 1, 10, 15 and 17. Thus, the rejection going to this 
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limitation should be withdrawn. 

With regard to the limitation of "accessing the package data" by the resolution module, 
however, Applicants respectfully disagree. In the present invention, if a customer selects an 
unresolved package, defined as a package having one or more products with at least one 
unresolved attribute, the resolution module allows the customer to resolve the unresolved 
attributes of the products that make up the package. In the specification, FIG. 3B and the 
associated text describe the process for resolving the unresolved package (page 10, line 12 to 
page 12, line 10). The specification provides: 

If the type 552 of the selection indicates that it is an unresolved package 
526 (Block 714), the resolution module 20 then determines the products 520 
possessed by the selected unresolved package 526, by matching the selected 
catalog entry identifier 550 with package identifiers 600, stored in the package 
relationship table 510. ... In the sample data provided, for explanatory purposes, 
it will be assumed that the unresolved package 526 selected by the customer 26 

has "150" as its catalog entry identifier 550 [FIG 2A (Catalog Entry Table)] 

In the sample provided, the data contained in the package relationship table 510 
indicates that the selected package 526 contains two products 520, having 
component identifiers 602 "101" and "102", respectively (which correlate to 
products 520 having matching catalog entry identifiers 550, ie. the sweater and the 
gloves). (Block 715) [FIG. 3B] 

For each product 520 contained in the selected package 526 (which will be 
referred to as a "selected product" 520), the resolution module 20 then determines 
the attribute types 562 possessed by the selected product 520 (which will be 

-9- 



Attorney Docket: CA920000056US 1/2178P 

referred to as "selected attribute types" 562), by matching the catalog entry 
identifiers 550 of the selected product 520 with product identifiers 564, stored in 
the product attribute table 502. In the example provided, the resolution module 
20 "determines" that the selected sweater product 520 has two unresolved selected 
attribute types 562 (sweater-size and sweater-colour) and that the selected gloves 
product 520 has one unresolved selected attribute type 562 (gloves-material) that 
must be resolved in order to complete the purchase. (Block 716) 

As will be understood, for each such selected attribute 562 (and correlated 
attribute identifier 560) for each selected product 520, the resolution module 20 
requires the customer 26 to select attribute values for the selected product 520. 
The resolution module 20 ensures that the customer 26 has selected attribute 
values 574 found in the attribute value field 574 of the product attribute value 
table 504 having an attribute identifier 572 matching that of the selected attribute 
identifier 560. The corresponding selected item identifier 576 (which corresponds 
to the related catalog entry identifier 550) is then determined. If the item 
identifiers 576 for all of the selected attribute values 574 for a selected product 
520 do not match, or if an acceptable attribute value 574 cannot be located in the 
table 504, the resolution module 20 will direct the consumer 26 to either specify 
acceptable attribute values 574 or will reject the selection of the product 526. 
(Block 718) 

Once the selected catalog entry identifiers 550 have been determined for 
the selected products 520, the resolution module 20 then matches the selected 
catalog entry identifiers 550 with the component identifiers 604 ("selected 
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component identifiers") in the package relationship table 510. If a package 
identifier 600 can be located in the relationship table 604 which correlates to all of 
the selected component identifiers 604, the catalog entry identifier 550 matching 
the selected package identifier 600 is then added to the customer's 26 shopping 
cart, as will be understood. If such an acceptable package identifier 600 cannot be 
located in the table 510, the resolution module 20 will direct the consumer 26 to 
either redesignate acceptable attribute values 574 or will reject the selection of the 
unresolved package 526. (Block 720) 
Specification, page 10, line 12 to page 12, line 10. 

Among other things, the resolution module determines the products 520 in the selected 
unresolved package "by matching" the catalog entry identifier 550 in the Catalog Entry Table 
500 (FIG. 2A) with package identifiers 600 in the Package Relationship Table 510 (FIG. 2F). In 
order to "match" the catalog entry identifier 550 with the package identifiers 600, the resolution 
module must "access" the Catalog Entry Table 500 to determine the catalog entry identifier 550 
associated with the selected unresolved package, and "access" the Package Relationship Table 
510 to determine the package identifiers 600, which indicate the products associated with the 
selected unresolved package. 

Similarly, when the resolution module determines the attribute types 562 for a product 
520, the resolution module matches the product's catalog entry identifier 550 (found in the 
Catalog Entry Table 500 (FIG. 2A)) with product identifiers 564 in the Product Attribute Table 
502 (FIG. 2B). Again, in order to perform this task, the resolution module necessarily "accesses" 
the data stored in a table. 
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Applicants respectfully submit that each step of the resolution process, e.g., steps 715 to 
720 of FIG. 3B and FIG. 3C, requires the resolution module to match data stored in one or more 
of the tables (FIGs. 2A-2F) stored within the catalog database 22. Those skilled in the art would 
readily appreciate that such matching is possible only if the resolution module has "access" to the 
data. 

Based on the reasoning above, Applicants respectfully submit that the specification of the 
application supports "resolving the at least one unresolved attribute of the one or more products 
in the selected unresolved package by accessing the package data correlated to the selected 
unresolved package," as recited in claims 1, 10, 15 and 17. No new matter has been presented. 



35U.S.C. $102 Rejections 

The Examiner rejected claims 1-25 under 35 U.S.C. § 102(e) as being anticipated by 

Mikurak (U.S. Patent No. 6,606,744). In so doing, the Examiner stated: 

As to claim 1, Mikurak discloses an e-commerce system [e.g., Fig. 4] for 
enabling the purchase of a package of products and services [e.g., Fig(s). 54-55], 
comprising: 

a) a catalog database [e.g., see the modules 5300, 5324 of Fig. 53; Fig. 80; 
the Application Database of Fig. 121] comprising package data correlated to at 
least one package [e.g. see col. 178, liens 19-46]. 

b) a selection module coupled to the catalog database for allowing a 
customer to select a package for purchase [e.g. see the shopping Cart processing at 
col. 96 et seq., Fig. 55]. 

c) a resolution module coupled to the catalog database for resolving 
unresolved attributes in the selected package [e.g. see the shopping basket 
function module at col. 97, lines 9-21]. 

Applicants respectfully disagree. 

The present invention is directed to an e-commerce solution that allows a customer to 

purchase a group of merchandise objects, known as a package. The package is predefined by the 

merchant. By grouping certain objects together to form a package and offering the package for 
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purchase, the merchant can reap promotional and other advantages. For example, the merchant 
can promote new or low volume products with more popular, high volume products, thereby 
increasing sales volume overall. 

The method and system of the present invention allows the merchant to define, and 
allows the customer to purchase, an unresolved package that includes one or more products that 
have at least one unresolved attribute. According to the method and system of the present 
invention, a database catalog is provided that includes a plurality of cross-referenced tables that 
enable the customer to resolve unresolved attributes in a selected package. One such table is a 
catalog entry table (see Figure 2A of the present invention), which includes package data 
correlated to the unresolved package. The package data in the catalog entry table defines which 
products make up a package. The catalog entry table (Figure 2A) is cross-referenced against a 
product attribute table (Figure 2B), which describes which attribute types are associated with a 
product. The product attribute table, in turn, is cross-referenced against a product attribute value 
table (Figure 2C), which defines one or more values for each attribute type. Together, these and 
other tables allow the customer to resolve unresolved attributes of products that make up an 
unresolved package for purchase. 

Accordingly the present invention, as recited in claims 1 and 10, provides: 

1 . An e-commerce system for enabling the purchase of a package, 
comprising: 

(a) a catalog database comprising a catalog entry table including 
package data correlated to at least one unresolved package, wherein the at least 
one unresolved package includes one or more products with at least one 
unresolved attribute; 

(b) a selection module coupled to the catalog database for allowing a 
customer to select an unresolved package for purchase; and 

(c) a resolution module coupled to the catalog database for resolving 
the at least one unresolved attribute of the one or more products in the selected 
unresolved package by accessing the package data correlated to the selected 
unresolved package. 
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10. An e-commerce method for enabling the purchase of a package, 
comprising the steps of: 

(a) providing a catalog database comprising a catalog entry table 
including package data correlated to at least one unresolved package, wherein the 
at least one unresolved package includes one or more products with at least one 
unresolved attribute; 

(b) allowing a customer to select an unresolved package for purchase; 

and 

(c) resolving the at least one unresolved attribute of the one or more 
products in the selected unresolved package by accessing the package data 
correlated to the selected unresolved package. 

Independent claims 15 and 17 are program product and computer-readable medium claims 

having scopes similar to claims 1 and 10, respectively. 

The primary reference, Mikurak, is related to a sprawling network system that includes 
"transfer of information across the internet utilizing telephony routing information and internet 
protocol address information." (Abstract). In one embodiment, Mikurak provides "a new kind 
of web architecture framework (called "WAF" in this document) that secures, administers, and 
audits electronic information use." (Col. 82, lines 8-10). The WAF can be employed to generate 
a framework "like the one shown in FIG. 53 to support various features such as an electronic 
commerce component 5300, a content channels component 5302, an administrative component 
5304, a customer relationship management component 5306, ... or a web customer service 
component 5312." (Col. 82, lines 1-7). 

Mikurak is generally related to enabling and supporting commerce related web 
application services, such as shopping from a virtual catalog (col. 91, line 15 et seq.). In one 
section, Mikurak describes allowing a customer to buy products and services from a virtual 
catalog (col. 91, lines 17-42; Figure 54), and in another section, Mikurak describes a shopping 
cart function (col. 96, line 20 to col. 98, line 50). In yet another section, Mikurak describes 
allowing a customer to customize an item for purchase (col. 100, lines 1-42). In each of these 
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descriptions, Mikurak provides conceptual ideas, but does not take the next step in teaching or 
suggesting how one would implement such conceptual functions. The present invention takes 
this step. 

Independent Claims 1, 10, 15 and 17 

While Mikurak describes conceptually web based commerce, Applicants respectfully 
submit that Mikurak fails to teach or suggest the implementation described by the cooperation of 
elements recited in independent claims 1, 10, 15 and 17 of the present invention. In particular, 
Mikurak fails to teach or suggest "resolving the at least one unresolved attribute in the selected 
unresolved package by accessing the package data correlated to the selected unresolved 
package," where the package data is in "a catalog entry table" in a "catalog database." 

Although Mikurak teaches an application database coupled to a database server in Figure 
121, that database stores "application specific data" (col. 178, lines 16-27), and not "a catalog 
entry table including package data correlated to at least one unresolved package," as recited in 
claims 1, 10, 15 and 17. Moreover, although Mikurak discloses the concept of allowing the 
customer to select available features of each of the items to be purchased (col. 100, lines 18-24), 
it fails to teach or suggest resolving the unresolved attributes of products in a package "by 
accessing the package data correlated to the selected unresolved package," as recited in claims 1 , 
10, 15 and 17. 

Because Mikurak fails to teach or suggest the cooperation of elements recited in claims 1, 
10, 15 and 17, Applicants respectfully submit that claims 1, 10, 15 and 17 are allowable over 
Mikurak. Because claims 2-9, 1 1-14, 16, and 18-25 depend on claims 1, 10, 15 and 17, the 
above arguments are applicable, and for the reasons presented above, they too are allowable over 
Mikurak. 
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Claims 2, 11. 16 and 18 

Applicants respectfully submit that claims 2, 1 1, 16 and 18 are allowable over Mikurak 

for additional and alternative reasons. Claims 2 and 1 1 recite: 

2. The system of claim 1 wherein the catalog database further 
comprises: 

(d) item data correlated to a plurality of items, wherein each item is 
fully resolved; 

(e) a product attribute table that defines for each product at least one 
attribute type associated with the product; and 

(f) a product attribute value table that defines at least one value for 
each attribute type. 

1 1 . The method as claimed in claim 1 0, wherein the catalog database 
further comprises a product attribute table and a product attribute value table, 
wherein the product attribute table defines for each product at least one attribute 
type associated with the product, and the product attribute value table defines at 
least one value for each attribute type. 

Claims 16 and 18 are program product and computer-readable medium claims having scopes 

similar to claims 2 and 1 1 , respectively. 

Mikurak fails to teach or suggest "a product attribute table" and "a product attribute value 
table," as recited in claims 2, 1 1, 16 and 18. The Examiner contends that Mikurak "discloses the 
catalog database comprising item data, product data and attribute data [e.g., see the Item catalog 
screen processing, col. 97, line 49-59]." Applicants respectfully disagree. The cited portion of 
Mikurak describes an item catalog screen on which information on items is provided. The 
consumer places items into the shopping basket and the consumer is able to examine the 
shopping basket's contents at any time. 

There is no mention or suggestion of "a product attribute table" that "defines for each 
product at least one attribute type associated with the product," and/or "a product attribute value 
table" that "defines at least one value for each attribute type," as recited in claims 2, 11, 16 and 
18. For this reason, Applicants respectfully submit that claims 2, 1 1, 16 and 18 are allowable 
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over Mikurak. 

Claims 12, 13, 14, 19, 20 and 21 

Applicants respectfully submit that claims 12 5 13, 14, 19, 20, and 21 are allowable over 
Mikurak for additional and alternative reasons. Claims 12, 13, and 14 recite: 

12. The method as claimed in claim 11, wherein resolving step (c) 
comprises utilizing the catalog entry table to determine automatically the one or 
more products in the selected unresolved package. 

13. The method as claimed in claim 12, wherein resolving step (c) 
further comprises, for each of the one or more products in the selected unresolved 
package, utilizing the product attribute table to determine automatically the at 
least one unresolved attribute type. 

14. The method as claimed in claim 13, wherein resolving step (c) 
further comprises allowing the customer to select an attribute value from the 
product attribute value table for the at least one unresolved attribute type thereby 
resolving the selected package. 

Claims 19, 20 and 21 are computer-readable medium claims having scopes similar to claims 12, 
13 and 14, respectively. 

Claims 12-14 and 19-21 elaborate on the resolving step/instruction (c) of claim 10 and 
claim 17, respectively. They disclose how the catalog entry table, the product attribute table and 
the product attribute value table are used to resolve the at least one resolved attribute in the 
selected unresolved package. 

As stated above, Mikurak is not directed to implementation. Rather it is devoted to 
conceptual ideas. Accordingly, Mikurak fails to teach or suggest utilizing the various tables 
described above (e.g., in claims 2, 1 1, 16 and 18) in the manner recited in claims 12-14 and 19- 
21, to resolve unresolved attributes in one or more products in a package. For this reason, 
Applicants respectfully submit that claims 12-14 and 19-21 are allowable over Mikurak. 
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Conclusion 



In view of the foregoing, Applicants submit that claims 1-25 are allowable over the cited 
reference. Applicants respectfully request reconsideration and allowance of the claims as now 
presented. 

Applicant's attorney believes that this application is in condition for allowance. Should 
any unresolved issues remain, Examiner is invited to call Applicant's attorney at the telephone 
number indicated below. 



Respectfully submitted, 



SAWYER LAW GROUP LLP 



August 4, 2004 
Date 




Attomeyfor Applicant(s) 
Reg. No. 48,681 
(650) 493-4540 
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